Maintenance releases of software shipped independently of the normal software release cycle are commonplace. Patches are deployed onto existing software installations (targets) to fix critical software problems (e.g., bugs) without the need to re-release an entire software package. Service packs are frequently used to combine a number of fixes and deploy them together. Deploying, installing, and uninstalling a patch or service pack, hereafter collectively referred to as a patch, present a number of problems which must be solved to ensure that a patch is installed correctly, maintains system consistency and integrity, functions properly, and can be uninstalled without side effects.
Properly installing a patch to a target can be complicated and require intricate working knowledge of the structure of the software being updated. A patch can be given an identifier and can include one or more of the following components: executable code, source code, libraries, configuration information, deployment information, artifacts, resources, audio/visual presentations, controls, data files, and other suitable components. Commonly available tools such as WinZip® (a registered trademark of WinZip Computing, Inc.) can be used to extract a patch's components on a target's computer system. Such tools can even build a hierarchical directory structure for the files as part of the extraction process.
Additional steps are still required to ensure that components added by the patch are placed in their proper location in the system, that modified components are replaced, and that deleted components are removed. These steps may be performed manually by a system administrator. However, most system administrators lack the requisite knowledge of a target's software architecture to manually perform these steps. More commonly, a patch installer process (e.g., an installation script) is included with the patch to perform the additional steps necessary to correctly install the patch. But creating patch installers consumes valuable development time which could be better focused on creating and maintaining the software itself.
The use of shared code can also complicate the process of correctly patching a target software system. Controls, libraries, and other shared code are utilized to perform common tasks across pieces of a target and to reduce development and testing time. Installing a patch for shared code intended to solve a problem in one target piece but may cause a different problem for another piece using the same shared code. Therefore it is important that patches be installed on the system so that only the intended target pieces utilize them. Installing a new version of the target system onto an existing, previously patched installation can also result in confusion and the improper operation of the system. There is risk that an older version of shared components may be used instead of the updated components.
Although patches are intended to solve customer problems or provide new functionality, in some cases a patch may contain side effects or bugs which result in unintended behaviors. When this occurs, the patch may have to be removed from the system. The process of removing a patch may be complicated by the number of components included in the patch, the number of target pieces which use the patch components and whether additional patches have been installed subsequent to the patch to be removed. The process removing the patch must ensure that each component included in the patch is replaced with the appropriate prior version of the component. This generally requires an administrator or a process to first remove all patches installed subsequent to the patch being removed in the reverse order in which they were installed. Once the subsequent patches have been removed, the patch can be removed and the subsequent patches reinstalled to return the system to the desired state. However, this is a cumbersome and time consuming procedure that is naturally prone to error due to the number of steps involved.